Retransmission mechanisms, also known as automatic repeat request (ARQ) techniques, constitute an approach that addresses the loss of data on its way to the intended recipient. Such data loss can be the result of unfavourable physical conditions such as interference, noise, or multipath propagation.
ARQ techniques are based on status reports that are transmitted from a recipient of the data to indicate to the transmitter that individual data units have either been successfully received (positive acknowledgement) or lost (negative acknowledgement). Generally, the recipient generates the status reports event-based, timer-based or poll-based according to specifications of the respective ARQ protocol. Status reports may for example be scheduled after receipt of a predetermined number of data units or at predefined points in time.
The transmitter evaluates the received status reports and then decides about the retransmission of individual data units that have not or not correctly been received at the recipient. Some ARQ techniques provide for an automatic retransmission of a data unit for which no positive acknowledgement has been received within a predetermined time interval after the first transmission of the data unit.
With regard to the open systems interconnection (OSI) layer model, ARQ techniques are usually implemented on the data link layer (layer 2 or L2). The data link layer is located between the physical layer (layer 1 or L1) and the network layer (layer 3 or L3) as indicated by the protocol stack 10 shown on the left-hand side of FIG. 1.
The physical layer L1 defines the electrical and physical specifications for the network components involved in the data transfer. The data link layer L2 provides the mechanisms to transfer data between the individual network components and to detect and possibly correct errors that may occur in the physical layer L1. The network layer L3 performs network routing, flow control, segmentation/desegmentation, and error control functions. The best known example of a L3 protocol is the Internet protocol (IP).
Usually, there are one or more additional layers on top of the network layer L3. In the example shown on the left-hand side of FIG. 1, these additional layers include a transport layer L4 configured according to the transmission control protocol (TCP) and an application layer L7 configured according to the file transfer protocol (FTP). While not part of the official OSI model, additional protocols may operate between the data link layer L2 and the physical layer L1. These protocols are sometimes referred to as “layer 2.5” protocols.
In the exemplary configuration shown in FIG. 1, the data link layer L2 is divided into two sub-layers, the radio link control (RLC) layer and the medium access control (MAC) layer, respectively. The ARQ techniques are in most cases implemented within the RLC sub-layer as will now be explained in more detail with reference to the right-hand side of FIG. 1.
In the configuration shown in FIG. 1, the RLC sub-layer includes a first buffer 12 interfacing the network layer L3 and a second buffer 14 interfacing the MAC sub-layer. The first buffer 12 is provided for storing incoming service data units (SDUs) such as IP packets 16 generated within the network layer L3. The SDUs stored in the first buffer 12 are read out by a segmentation engine 18 that segments the SDUs 16 into RLC protocol data units (PDUs) 20. The PDUs 20 are on the one hand forwarded to the MAC sub-layer for transmission to the intended recipient and, on the other hand, stored in the second buffer 14 for a possible re-transmission under the regime of an ARQ protocol.
At a certain point in time, a recipient of the PDUs may require a handover from a first network component (with a link layer entity having an RLC configuration as shown in FIG. 1) to a second network component (with a similar link layer entity). In the following, some possible handover scenarios will exemplarily be described with particular reference to processes occurring on the data link layer.
In principle, the handover from a currently serving link layer entity to a new link layer entity can occur without previous buffer synchronisation as shown in FIG. 2. In this case, when the handover is to be performed between two link layer entities, the stream of SDUs is switched from the previously serving link layer entity to the new link layer entity, and the content of the buffers 12, 14 of the previously serving link layer entity is simply discarded. It is evident that the resulting loss of buffered content will slow down the operation of higher layers and can result in a temporal degradation of the service quality.
According to an alternative handover scenario shown in FIG. 3, the handover can be performed such that before switching the SDU stream from the currently serving link layer entity to the new link layer entity, the content of the SDU buffer 12 of the currently serving link layer entity is transferred to the SDU buffer 12′ of the new link layer entity. This process is sometimes also called L3 context transfer. In this case, only the content of the PDU buffer 14 of the previously serving link layer entity is discarded. US 2004/0146033 A1 illustrates an exemplary technique for such an L3 context transfer.
One drawback of the handover approach illustrated in FIG. 3 is the fact that the data loss resulting from discarding the content of the PDU buffer 14 can still lead to a service degradation. Furthermore, the data loss may trigger higher layer protocol interactions, for example with TCP in the transport layer L4. Such higher layer protocol interactions are illustrated in FIG. 4. As can be gathered from the TCP trace shown in FIG. 4, several TCP segments are lost at the handover instant (see dark vertical line). The lost TCP segments will have to be retransmitted by TCP after the handover has occurred, which leads to a slow transmission start after the handover.
Additionally, the loss of TCP segments at the handover instant may result in a TCP timeout. Accordingly, frequent handovers may lead to the situation that a TCP sender is unable to attain a sufficiently high sending rate, thus leading to a radio link underutilization. Such a underutilization scenario is shown by the trace of the TCP congestion window CWND illustrated in FIG. 5.
One solution to avoid the problems illustrated in FIGS. 4 and 5 would be to make the handover actually lossless. To this end, all data currently being transmitted (and stored in the link layer PDU buffer) may be reconstructed. The SDUs reconstructed from the content of the PDU buffer may then be transferred to the new link layer entity in addition to the transfer of the SDU buffer content as shown in FIG. 3.
However, it has been found that such a reconstruction approach can cause unintentional data duplication as shown in the TCP trace of FIG. 6. This data duplication is a result of the fact that some of the reconstructed SDUs have already been successfully delivered to the recipient, but the corresponding PDUs have not yet been deleted from the PDU buffer.
The duplication shown in FIG. 6 tends to interfere with higher layer protocols such as TCP. TCP rejects two duplicate data packets with sending a TCP duplicate acknowledgement back to the TCP sender, which leads to TCP error recovery. The duplicate acknowledgement leads to a behaviour of the TCP congestion window CNWD as shown in FIG. 7. This behaviour indicates that the radio link is not fully utilized most of the time. Obviously, such an underutilization constitutes a waste of available resources.
Therefore, there is a need for an improved handover technique on a link layer level that is more compatible with ARQ protocols.